Напомним, что у компании StarWind есть отличное бесплатное решение для миграции физических и виртуальных машин - V2V Converter. С помощью этого продукта вы можете преобразовать образ виртуальной машины, который у вас работает на одной из платформ виртуализации, в нужный целевой формат ВМ, которая работает на базе виртуальных дисков соответствующего формата.

Давайте посмотрим, что в продукте появилось нового с начала этого года:

• Добавлена поддержка конвертации виртуальных машин в Proxmox и из Proxmox
• Улучшена функциональность конвертации для oVirt (OLVM и RHV)
• Добавлена поддержка конвертации работающих виртуальных машин с ESXi в Hyper-V
• Добавлена поддержка конвертации работающих виртуальных машин с Hyper-V на Hyper-V
• Добавлена поддержка миграции виртуальных машин напрямую с хостов oVirt
• Добавлена поддержка конвертации виртуальных машин в Oracle VirtualBox и из Oracle VirtualBox

Скачать StarWind V2V Converter можно совершенно бесплатно по этой ссылке.

В мае 2022 года компания Broadcom объявила о приобретении компании VMware за 61 миллиард долларов, что стало новым этапом в развитии главного вендора в сфере виртуализации. Данное поглощение стало вторым по цене за 2022 год — еще большую цену предложили только за игровой гигант Activision Blizzard, который приобрела корпорация Microsoft за $68,7 млрд. Согласно договорённости, акционеры VMware получили премию...

Сейчас многие администраторы виртуальных инфраструктур VMware vSphere и Microsoft Hyper-V используют лидирующее на рынке решение StarWind Virtual SAN для создания отказо- и катастрофоустойчивых хранилищ под виртуальные машины. В прошлой статье мы рассматривали развертывание модуля StarWind SAN & NAS storage appliance а сегодня мы поговорим о его первоначальной настройке, которая может быть проведена через графическую консоль (Web Console) или текстовый интерфейс (Text Console)...

Многие администраторы виртуальных инфраструктур VMware vSphere и Microsoft Hyper-V используют лидирующее на рынке решение StarWind Virtual SAN для создания отказо- и катастрофоустойчивых хранилищ под виртуальные машины. Как правило, продукт Virtual SAN устанавливается как виртуальная машина на гипервизорах ESXi и Hyper-V, чтобы использовать серверы как вычислительные узлы и серверы хранения одновременно. Это оптимальное решение для филиалов.

Сегодня мы поговорим еще об одном варианте развертывания этой платформы - StarWind SAN & NAS storage appliance. Данный модуль, построенный на базе ОС Linux, развертывается в одном из двух вариантов:

• На "голом железе" (bare metal), то есть на сервере без операционной системы. Это позволяет вам превратить сервер в полноценный узел кластера хранилищ (storage provider).
• На виртуальной машине - в этом случае сервисы хранилищ реализует ВМ на базе ОС Linux.

В обоих случаях StarWind SAN & NAS будет предоставлять гипервизорам сервисы хранения для виртуальных машин по протоколам iSCSI, SMB и NFS.

После развертывания у администратора появятся следующие интерфейсы управления инфраструктурой хранилищ StarWind:

• Веб-консоль StarWind
• Локальная текстовая консоль сервера
• Плагин к vCenter
• Удаленный интерфейс командной строки CLI для операций в кластере

Итак, для начала вам нужно убедиться, что сервер соответствует системным требованиям для решения StarWind SAN & NAS storage appliance. Если все в порядке, то загрузите ISO-образ продукта по этой ссылке: https://www.starwindsoftware.com/san-and-nas#download.

Установочный диск вы можете подготовить с помощью ПО Etcher или Rufus для Windows, либо командой dd на Linux или macOS. Для сетевой загрузки смонтируйте ISO-образ к серверу с помощью iDRAC, iLo или IPMI.

Далее зайдите в BIOS и включите Legacy boot mode, после чего выберите CD\DVD или удаленный интерфейс загрузки в качестве загрузочного устройства.

Если все прошло успешно, сервер начнет показывать стадии загрузки установщика StarWind SAN & NAS:

Далее появится лицензионное соглашение, которое надо принять:

Затем выбираем единственную опцию "Install StarWind SAN & NAS":

Указываем один из доступных дисков:

Все проверяем и подтверждаем выбор:

После этого начнется установка StarWind SAN & NAS:

По завершении установки нужно перезагрузить сервер:

После этого вы можете управлять сервером StarWind через веб-интерфейс:

В открывшемся First Run Wizard вы сможете настроить все необходимые параметры сервера хранилищ. О настройке StarWind SAN & NAS через веб или текстовый интерфейс, а также через CLI, мы поговорим в следующей статье.

Скачать бесплатную пробную версию StarWind SAN & NAS storage appliance можно по этой ссылке.

Много лет назад мы писали о технологиях работы кэша write-through и write-back в ведущем на рынке виртуализации хранилищ решении StarWind Virtual SAN. С тех пор механика работы этих технологий была улучшена, но принципы остались теми же, как и большинство фундаментальных технологий. Сегодня мы поговорим о работе кэшей уровней L1 и L2, которые существенно улучшают быстродействие операций ввода-вывода.

При работе StarWind Virtual SAN с хранилищами используется кэш первого уровня (L1), располагающийся в оперативной памяти, а также кэш второго уровня (L2), размещенный на SSD-дисках, обеспечивающих высокое быстродействие системы.

StarWind использует традиционную оперативную память серверов (RAM) как буфер на чтение (write buffer) и L1-кэш, чтобы кэшировать операции записи, флэш-память SSD уже обслуживает кэш уровня L2. Оба кэша используют одни и те же алгоритмы - shared library, поэтому информация ниже применима, в основном, к кэшам обоих уровней. Об их отличиях мы также поговорим в статье отдельно.

При переполнении кэша нужно освободить его, используя какой-то алгоритм. StarWind применяет для этого алгоритм LRU - least recently used, то есть вытесняются данные (блоки), которые используются реже всего в последнее время.

В зависимости от степени исчерпания состояния кэша, его блоки могут находиться в одном из трех состояний: dirty, clean и empty. В самом начале блок помечается как empty - в нем нет данных, то есть блоки кэша не ассоциированы с блоками на диске. При работе кэша эти данные начинают заполняться. Блок помечается как dirty - если полезные данные были записаны в него, но еще не были записаны на диск (он не подтвердил запись данных). Блок помечается как clean, если данные из кэша были записаны на диск, либо блок кэша был записан в результате чтения в кэш блока с диска - то есть блок кэша и блок на диске содержат одинаковые данные.

Помните, что стандартный размер блока для кэша - 64 КБ.

Следующее полезное понятие - это прогрев кэша (cache warm-up). Эта концепция имплементируется на нижнем уровне в рамках сценария "in-memory" файловой системы LSFS (log-structured file system). Данные в кэш в этом случае попадают с диска, с учетом самых последних данных, записанных на диск.

Политики кэширования

Политика кэширования определяется вместе с другими параметрами кэша / устройств, когда они создаются. В StarWind Version 8 Release 5 режим работы кэша может быть изменен на лету для уже существующих устройств.

Write-back caching

Это режим, когда запись данных производится в кэш, но операция ввода-вывода (I/O) подтверждается, как запись на диск. Запись в основную память производится позже (при вытеснении или по истечению времени), группируя в одной операции несколько операций записи в соседние ячейки. Этот тип кэширования существенно ускоряет скорость записи данных на диск, однако имеет несколько меньшую надежность с точки зрения записи данных.

Если блок находится в статусе empty или clean, то запись в кэш происходит практически мгновенно, на уровне скорости записи данных в RAM или на SSD. А вот как работает кэш в разных обстоятельствах:

• Если операции записи не были сделаны в dirty-кэш на протяжении некоторого времени (по умолчанию 5 секунд), то данные записываются на диск. Блок переходит в состоянии clean, но данные в нем остаются.
• Если все доступные блоки кэша находятся в состоянии dirty, то данные, хранимые в самых старых блоках, форсированно скидываются на диск, а новые данные записываются в эти блоки. В этом случае производительность кэша несколько падает из-за требующихся операций записи на диск, и она сравнима со скоростью такой операции с диском.
• Если происходит сбой в работе сервера или памяти (или его выключают на обслуживание), то данные в кэше write-back, помеченные как dirty, немедленно сбрасываются на диск. Если размер кэша большой (гигабайты), то эта операция может занять значительное время. Его можно оценить так: Flushing time = cache size / RAM write.

Политика кэширования write-back ускоряет производительность в следующих случаях:

• Флуктуации нагрузки - кэш позволяет сгладить пики нагрузки за счет аккумуляции большого числа записей в кэше во время всплесков до момента снижения нагрузки.
• Постоянная перезапись тех же самых блоков - в этом случае они постоянно перезаписываются только в кэше, а на диск сбрасываются пачки блоков по мере необходимости.

Помните, что политика write-back предпочтительна для L1-кэша и в данный момент недоступна для L2-кэша, который всегда создается в режиме write-through.

Write-through caching

Это режим, когда запись производится непосредственно в основную память и дублируется в кэш. Такой тип кэширования не ускоряет запись данных на диск (но и не замедляет), но существенно увеличивает скорость чтения данных, которые можно взять из кэша. Этот тип кэша безопасен с точки зрения надежности данных и дает однозначный выигрыш в производительности.

При использовании этого типа кэширования не будет потери данных в случае неисправности сервера и памяти. Блоки памяти кэша в этом случае всегда помечены как clean.

Рекомендации по использованию кэша

L1 Cache

Он решает следующие проблемы:

• Запросы партнерского узла StarWind Virtual SAN могут приходить с небольшой задержкой и изменять порядок доступа к блокам, например, 1-2-3-4-5-6-7-8 изменится на 1-3-2-4-5-7-6-8. В этом случае L1- кэш сгладит поток последовательных запросов на запись с применением алгоритма round robin в дополнение к кэшированию. L1-кэш объединяет маленькие запросы записи в большие (write coalescing). Например, 16 запросов по 4k в кэш будут записаны на диск как единый блок 64к, что работает гораздо быстрее. Поэтому для такого кэша не нужно много памяти - от 128 МБ.
• L1 также компенсирует перезапись в те же секторы диска. Самая частая перезапись - это небольшие по размеру операции. Размер кэша должен зависеть от от частоты перезаписи данных и размера working data set. Чем чаще перезапись, теперь меньше вы можете делать кэш, но если больше размер working data set, то должен быть и больше кэш. В этом случае работает формула Tcached = Tdisk * (1 – (cache size) / (working set size)). В этом случае, если у вас кэш составляет 0.1 от data working set, процессинг данных будет составлять 0.9 от времени процессинга данных на диск. Если же cache size = working data set, то средний процессинг команд будет примерно равен времени процессинга команд в памяти.

StarWind L1 cache в режимах write-back и write-through может быть использован для:  

• Файловых устройств StarWind HA image file на базе HDD-хранилищ в конфигурации RAID 10.  
• Устройств StarWind LSFS на базе HDD в конфигурациях RAID 5, 6, 50, 60. Также посмотриите статью о требованиях устройств LSFS.

Также помните, что в большинстве случаев для дисковых массивов all-flash кэш уровня L1 вам не потребуется.

В идеале размер кэша L1 должен быть равен размеру working data set. Также размер кэша L1 влияет на время, которое вам потребуется, чтобы выключить сервер (нужно сбросить грязные блоки на диск). Также помните, что лучше не делать L1 кэш в режиме WB, чтобы не создавать ситуацию, когда большой объем данных может быть утерян.

При использовании кэша L1 в режиме write-back обязательно используйте UPS для серверов, чтобы не потерять часть данных. Время работы UPS должно позволяет сбросить содержимое грязного кэша на диск.

L2 Cache (Flash Cache)

Для обслуживания кэша L2 создается обычное устройство ImageFile device. У этого устройства нет таргета, и оно соединено с системой точно так же, как и устройство с данными (ImageFile or LSFS).

Система с кэшем L2 должна иметь больше оперативной памяти RAM для обеспечения накладных расходов. Формула тут такая: 6.5 ГБ RAM на 1 ТБ кэша L2, чтобы хранить метаданные. Более подробно о кэше L2 можно почитать в базе знаний StarWind.

StarWind L2 cache может быть использован для следующих сценариев:

• HA-устройства StarWind image file на базе HDD в конфигурации RAID 10.
• Устройства StarWind LSFS на базе HDD в конфигурации RAID 5, 6, 50, 60.
• HA-устройства StarWind image file на all-flash хранилищах в некоторых сценариях. Более подробно об этих сценариях можно почитать в базе знаний StarWind.

В большинстве случаев, когда у вас есть L1 кэш, кэш уровня L2 вам не потребуется. Размер L2 кэша должен быть равен среднему объему уникальных данных, запрашиваемых с хранилища на регулярной основе (определяется экспериментально).

Продолжаем рассказывать о главном продукте для создания отказоустойчивых хранилищ StarWind Virtual SAN, который позволяет обеспечивать бесперебойное функционирование кластеров виртуальных машин на базе серверов виртуализации VMware ESXi или Microsoft Hyper-V. Сегодня мы рассмотрим механизм назначения прав доступа инициаторов в консоли StarWind Management Console, с помощью которой администраторы управляют всеми аспектами виртуальных хранилищ.

Многие из вас используют или интересуются решением StarWind Virtual SAN, которое является сейчас одним из основных продуктов на рынке для организации отказоустойчивых кластеров хранилищ (а еще и самым технологически продвинутым). Сегодня мы поговорим об узле Witness node в кластерах и о том, как он помогает защитить его от массовых сбоев в виртуальной среде.

Многие из вас знают компанию StarWind Software, лидера в сфере поставки программных и программно-аппаратных решений для создания отказоустойчивых хранилищ. Помимо решений непосредственно для организации хранилищ, у компании есть и виртуальный модуль StarWind Backup Appliance, который предназначен для резервного копирования виртуальных машин на хранилищах StarWind. Это программно-аппаратный комплекс на базе оборудования NVMe, который позволяет избавиться от проблемы производительности хранилищ резервных копий и забыть о задаче планирования окна резервного копирования.

Модуль StarWind Backup Appliance поставляется в виде настроенного и готового к работе сервера резервного копирования, построенного на базе StarWind HyperConverged Appliance (HCA). Работа с продуктом происходит через удобный веб-интерфейс StraWind Web UI, есть также плагин StarWind для vCenter.

В апреле компания StarWind объявила, что StarWind Backup Appliance теперь включает в себя оборудование GRAID SupremeRAID - первую в мире карточку NVMe-oF RAID, которая обеспечивает высочайший уровень защиты данных в рамках технологии NVMe RAID на рынке.

Традиционные RAID-контроллеры не были разработаны изначально для технологии NVMe, а программные RAID работают недостаточно эффективно, потребляя при этом большое число циклов CPU, что мешает рабочим нагрузкам сервера. Поэтому с теперь помощью карточек GRAID комплексы StarWind Backup Appliance обеспечат максимальную производительность и защиту данных на базе дисков NVMe SSD.

Вот так выглядят результаты тестов технологии GRAID по сравнению с текущими реализациями аппаратных RAID для NVMe:

Более подробно об этом нововведении можно узнать из пресс-релиза StarWind. Скачать пробную версию StarWind Backup Appliance можно по этой ссылке.

Многие компании сталкиваются сегодня с необходимостью переезжать на другую платформу виртуализации из-за сложностей, связанных с поддержкой зарубежных решений, а также ростом курсов валют. Сегодня мы расскажем об одной из альтернатив, которую предлагает российскому бизнесу компания HOSTVM, и рассмотрим алгоритм миграции на платформу. Сама по себе платформа HOSTVM представляет собой российскую версию гипервизора, построенного на базе открытого исходного кода KVM...

Многим из вас знакома компания StarWind Software, выпускающая одни из лучших в отрасли продукты для организации отказоустройчивых хранилищ под платформы виртуализации. Компания производит как программные продукты (StarWind Virtual SAN для vSphere и Hyper-V), так и программно-аппаратные комплексы, представленные линейкой StarWind HyperConverged Appliance (HCA) и StarWind Storage Appliance. Сегодня мы поговорим именно о программно-аппаратных решениях StarWind Appliances...

Продолжаем рассказывать технические подробности о работе продукта StarWind Virtual SAN, позволяющего создавать программные и программно-аппаратные отказоустойчивые кластеры iSCSI для виртуальных сред. Сегодня мы поговорим о расширенных настройках протокола iSCSI на стороне StarWind и на стороне VMware ESXi, чтобы обеспечить непрерывное функционирование приложений в виртуальных машинах при обрыве соединений.

Стек работы с хранилищами VMware ESXi настроен таким образом, чтобы адекватно реагировать на кратковременную потерю сигнала в канале iSCSI, которая может возникнуть по разным причинам (кто-то перекоммутировал соединение, дрогнул порт и т.п.). По умолчанию расширенные настройки iSCSI выставлены так, чтобы переживать кратковременные сбои в рамках одного пути в интервале 25-35 секунд. В это время I/O-запросы будут копиться в очереди, а потом, либо произойдет продолжение передачи при восстановлении текущего соединения, либо хост переключится на резервный путь (failover) текущего или резервного адаптера.

В то время, как такое поведение не является критичным для большинства приложений, иногда есть специфические требования, которые надо выполнять для отдельных систем. Например, если речь идет о системе видеонаблюдения, то там задержка в полминуты является неприемлемой, и ее надо обрабатывать быстрее.

Для этого, если вы используете хранилища StarWind Virtual SAN, есть специальные настройки реагирования на подобные ситуации.

Итак, для начала вам нужно остановить службы StarWind Virtual SAN:

• В консоли StarWind Management Console проверить, что все устройства StarWind HA находятся в статусе "Synchronized" на всех серверах
• Проверить, что все датасторы имеют активные задублированные пути для всех серверов StarWind, а политика доступа по нескольким путям (MPIO) установлена в Round Robin
• На StarWind VSAN для Windows нужно выполнить команду для остановки служб StarWind: net stop starwindservice
• На виртуальном модуле StarWind VSA нужно выполнить такую команду: systemctl stop StarWindVSA

Далее открываем конфигурационный файл:

• На StarWind VSAN для Windows: C:\Program Files\StarWind Software\StarWind\StarWind.cfg
• На виртуальном модуле StarWind VSA: nano /opt/StarWind/StarWindVSA/drive_c/StarWind/StarWind.cfg

Далее там находим параметр iScsiPingCmdSendCmdTimeoutInSec и выставляем его значение, например в "1" (одна секунда).

Ну и, наконец, надо запустить службы StarWind VSAN:

• На StarWind VSAN для Windows: net start starwindservice
• На виртуальном модуле StarWind VSA: systemctl start StarWindVSA

Теперь нужно добраться до расширенных настроек iSCSI инициатора VMware ESXi. Открываем Advanced Options для адаптера в разделе Storage Adapters нужного нам инициатора:

И смотрим, какие настройки там выставлены:

Нас интересует:

• RecoveryTimeout - это как раз время, через которое активный путь помечается как "мертвый" (переводится в DEAD_STATE), когда по нему больше не приходит команд ввода-вывода.
• NoopInterval - это интервал, с которым происходит пассивное тестирование неактивных путей на предмет того, живы ли они.
• NoopTimeout - это время, через которое происходит пометка неактивного пути как DEAD, если по нему не получено ответа.

Эти настройки по умолчанию установлены в оптимальные с точки зрения вероятности отказа/потерь значения. Меняйте их только, если у вас есть особые требования приложений по непрерывной доступности хранилищ, и вы знаете, какое поведение системы хотите получить. Уменьшение таймаутов, очевидно, ведет к загрузке сети пингами каналов iSCSI и дополнительной нагрузке на устройства.

Довольно давно мы писали о технологии Remote Direct Memory Access (RDMA) которая позволяет не использовать CPU сервера для удаленного доступа приложения к памяти другого хоста. RDMA позволяет приложению обратиться (в режиме чтение-запись) к данным памяти другого приложения на таргете, минуя CPU и операционную систему за счет использования аппаратных возможностей, которые предоставляют сетевые карты с поддержкой этой технологии - называются они Host Channel Adaptor (HCA).

Также некоторое время назад мы писали о VMware Paravirtual RDMA (PVRDMA) - технологии, поддержка которой появилась еще в VMware vSphere 6.5. С помощью нее для сетевых адаптеров PCIe с поддержкой RDMA можно обмениваться данными памяти для виртуальных машин напрямую через RDMA API, что важно для нагрузок High Performance Computing (HPC) на платформе vSphere.

Работает PVRDMA только в окружениях, где есть хосты ESXi с сетевыми картами с соответствующей поддержкой, а также где виртуальные машины подключены к распределенному коммутатору vSphere Distributed Switch (VDS). Альтернативой этому режиму использования сетевых карт является технология VMDirectPath I/O (passthrough), которая напрямую пробрасывает устройство в виртуальную машину. Это, конечно, самый оптимальный путь с точки зрения производительности, однако он не позволяет использовать многие полезные технологии VMware, такие как HA, DRS и vMotion.

Недавно компания VMware выпустила интересный документ "Paravirtual RDMA for High Performance Computing", где рассматриваются аспекты развертывания и производительности PVRDMA, а также производится тестирование этой технологии в сравнении с VMDirectPath I/O и TCP/IP:

Читать весь документ, наверное, не стоит - можно довериться методике тестирования VMware и ее подходу к оценке производительности. Тестовый стенд выглядел так:

Состав оборудования и особенности тестирования:

• 8 хостов ESXi 7.0 на платформе PowerEdge C6420 с Intel Xeon Gold 6148 CPU на борту (20 ядер / 40 потоков), 200GB RAM NVIDIA Mellanox ConnectX-5 Ex 100GbE NIC на канале RDMA
• Карты NVIDIA Mellanox ConnectX-5 Ex NIC, соединенные через коммутатор 100GbE NVIDIA Mellanox
• CentOS 7.6, 20 vCPUs, 100GB RAM, ВМ на датасторе vSAN, одна ВМ на хост ESXi
• OpenMPI версии 4.1.0, использующая using openib BTL для транспорта RDMA
• OpenFOAM версии 8, исполняющая тест cavityFine из руководства OpenFOAM. Этот тест исполняет симуляцию течения жидкости с заданными параметрами.

Тут можно просто взглянуть на следующие картинки, чтобы понять, что при использовании PVRDMA вы теряете не так уж и много в сравнении с VMDirectPath I/O.

Результаты теста по времени исполнения в секундах (для 2,4 и 8 хостов, соответственно):

Визуализация результатов при изменении числа узлов:

В среднем, потери производительности на PVRDMA составляют до 20%, зато вы получаете множество преимуществ, которые дает полная виртуализация без жесткой привязки к оборудованию - консолидация, HA и vMotion:

В сравнении с TCP дела тоже обстоят хорошо, результат лучше на 30-80%, в зависимости от числа узлов:

Скачать документ VMware Paravirtual RDMA for High Performance Computing можно по этой ссылке.

Продолжаем рассказывать вам о продуктах компании StarWind, которая является одним из лидеров в сфере производства программных и программно-аппаратных хранилищ виртуальных машин на платформах VMware vSphere и Microsoft Hyper-V. Сегодня мы расскажем о бесплатной утилите V2V Converter / P2V Migrator, которая позволяет делать три важных для администратора вещи...

Аналитическая компания Gartner выпустила отчет "2021 Magic Quadrant for Hyperconverged Infrastructure Software", отражающий ситуацию на рынке гиперконвергентной инфраструктуры. Это такая инфраструктура, где все ее вычислительные ресурсы, системы хранения и сети виртуализованы и собраны в единую интегрированную сущность и управляются из одной точки.

Компания VMware заняла в этом квадранте место лидера (надо отметить, что учитывались не только онпремизные, но и облачные HCI-инициативы), расположившись рядом со своим главным конкурентом в этой сфере - компанией Nutanix:

Может показаться, что многие вендоры гиперконвергентных решений просто сошли с дистанции за пару лет. Давайте взглянем на тот же квадрант за 2018 год, где были решения от HPE, Dell EMC и Cisco:

Но дело совсем не в этом, просто поменялась методика определения игроков - теперь в квадрант добавляют только тех вендоров, которые предоставляют интегрированное решение для гиперконвергентной инфраструктуры на базе серверов, а значит оттуда убрали Cisco, Dell EMC, HPE, Huawei и Red Hat. Более подробно об этом вы можете почитать здесь.

VMware занимает место в квадрате лидеров заслуженно, несмотря на то, что не занимается производством аппаратного обеспечения. Очевидно, что в гиперконвергентной среде сложно построить инфраструктуру на базе одного вендора, поэтому в любом случае нужны решения для виртуализации и агрегации ресурсов.

Приятно также видеть среди ведущих HCI-производителей компанию StarWind Software, флагманским продуктом которой в HCI-сфере является программно-аппаратное решение StarWind HyperConverged Appliance (HCA), о котором мы писали вот тут.

Скачать отчет 2021 Magic Quadrant for Hyperconverged Infrastructure Software можно по этой ссылке.

Как все из вас знают, не так давно компания VMware выпустила обновление своей серверной платформы виртуализации vSphere 7 Update 3. Мы писали также о нововведениях в отношении хранилищ, обновлении 3a, новых возможностях продукта vSAN 7 U3 и обновлениях vCenter и vSphere Client.

Сегодня мы поговорим об улучшениях в плане производительности платформы VMware vSphere 7 Update 3, о которых рассказано в обновившемся недавно документе "What’s New in Performance for VMware vSphere 7?". О похожем документе о производительности платформы vSphere 7 Update 2 мы писали в начале осени тут.

Давайте посмотрим, что нового в vSphere 7 U3 в плане производительности:

1. Масштабируемость виртуальных машин

Теперь максимальные параметры ВМ, доступных в vSphere выглядят так:

2. Оптимизации рабочих нагрузок, чувствительных к задержкам

Гипервизор VMware ESXi был еще больше оптимизирован, чтобы быстрее исполнять приложения, чувствительные ко времени отклика и задержкам (ultra-low-latency applications), уменьшены jitter и interference для приложений реального времени. Для этого было сделано множество оптимизаций в плане обработки прерываний. Чтобы воспользоваться этой функцией (low-latency mode) ее надо включить в BIOS машины.

3. Технология vSphere Memory Monitoring and Remediation (vMMR)

Размер памяти DRAM влияет на 50-60% стоимости самого сервера. При этом 1TB DRAM - это уже 75% этой стоимости. Поэтому VMware давно борется с этим, и одна из возможных оптимизаций здесь - использование Intel Optane Persistent Memory Mode, когда железо использует DRAM как кэш и представляет PMem как основную память системы. PMem более дешевая технология, но имеет побольше задержки (latency).

С помощью vSphere Memory Monitoring and Remediation (vMMR) можно следить за работой памяти в режиме Intel PMem Memory Mode и получать алерты когда ESXi исчерпывает память DRAM, что может привести к падению производительности сервера.

4. NVMe over TCP/IP

В релизе vSphere 7.0 была анонсирована поддержка технология NVMe over Fabrics, где первоначально поддерживались только протоколы FC и RDMA. Теперь же поскольку SSD-хранилища продолжают набирать популярность, а транспорт Non-Volatile Memory Express (NVMe) стал стандартом для многих типов систем, в vSphere 7 Update 3 появилась поддержка и NVMe over TCP, которая позволяет использовать стандартную инфраструктуру TCP/IP, оптимизированную под Flash и SSD, для трафика хранилищ. Это поможет в некоторых случаях существенно сэкономить на оборудовании при поддержании высокого уровня производительности.

Больше подробностей о производительности VMware vSphere 7 вы найдете в документе "What’s New in Performance for VMware vSphere 7?".

Многим из вас знакомы продукты компании StarWind, предназначенные для создания отказоустойчивых хранилищ под различные платформы виртуализации. Сегодня мы поговорим о том, как настраивать аутентификацию доступа к хранилищам через протокол CHAP в решении StarWind Virtual SAN...

Вчера мы писали о новых возможностях анонсированного недавно обновления платформы виртуализации VMware vSphere 7 Update 3. Сегодня мы чуть детальнее разберем возможности обновленного продукта, касающиеся хранилищ виртуальных машин. Нововведения были сделаны в следующих областях:

1.Поддержка NVMe over TCP

В релизе vSphere 7.0 была анонсирована поддержка технология NVMe over Fabrics, где первоначально поддерживались только протоколы FC и RDMA. Теперь же поскольку SSD-хранилища продолжают набирать популярность, а транспорт Non-Volatile Memory Express (NVMe) стал стандартом для многих типов систем, в vSphere 7 Update 3 появилась поддержка и NVMe over TCP, которая позволяет использовать стандартную инфраструктуру TCP/IP, оптимизированную под Flash и SSD, для трафика хранилищ. Это поможет в некоторых случаях существенно сэкономить на оборудовании.

2. Увеличение числа хостов на один датастор

У VMware есть какое-то количество клиентов, которые достигли предыдущего лимита в 64 хоста ESXi на одно виртуальное хранилище VMFS или NFS. В Update 3 этот лимит был расширен до 128 хостов. Надо понимать, что к лимитам кластера это число не имеет отношения - это только число хостов, которые могут одновременно использовать датастор.

3. Affinity 3.0 и поддержка CNS

В vSphere 7 компания VMware обновила Affinity Manager до версии 2.0, который уменьшает затраты на первые операции записи для thin и lazy thick дисков. В Affinity 3.0, который вошел в этот релиз, появилась поддержка персистентных томов Cloud Native Storage (CNS), которые также называются FCD (First Class Disks). Также добавлена поддержка большего числа хостов ESXi на один кластер.

4. Пакетные снапшоты томов vVols

В этом обновлении vSphere была существенно улучшена процедура обработки большого одновременного количества снапшотов томов vVol, которая может происходит в рамках процессов обслуживания хранилищ и резервного копирования. Операции снапшотов группируются и обрабатываются в рамках пакетного процесса, уменьшается общее число операций, поэтому в итоге нагрузка на хранилища уменьшается.

Более подробно обо всех новых возможностях VMware vSphere 7 Update 3 в отношении хранилищ рассказано в этой статье.

Многие администраторы VMware vSphere в крупных компаниях рано или поздно сталкиваются с необходимостью создания кластеров из виртуальных машин, например, для использования технологии высокой доступности баз данных Oracle Real Application Clusters (RAC) или для создания систем непрерывной доступности на базе технологии VMware Fault Tolerance. При использовании кластерных решений необходимо, чтобы диски ВМ находились в режиме multi-writer, то есть позволяли...

Недавно мы писали о новом продукте StarWind SAN & NAS от лидера в сфере программно-аппаратных хранилищ под виртуализацию - компании StarWind. Он предназначен для создания программных хранилищ на основе серверов с установленным там гипервизором.

Ну а на днях вышло еще одно новое решение - StarWind Backup Appliance. Оно, как можно догадаться, предназначено для резервного копирования виртуальных машин на хранилищах StarWind. Это программно-аппаратный комплекс на базе хранилища NVMe, который позволяет избавиться от проблемы производительности хранилищ резервных копий и забыть о задаче планирования окна резервного копирования.

Теперь бэкап на такое хранилище можно делать в любое время и без влияния на работу приложений и служб. За счет использования этого комплекса время резервного копирования у вас снизится минимум в 2 раза.

Более того, в случае сбоя вы сможете мгновенно восстановить виртуальные машины и файлы напрямую из резервной копии, обеспечив наилучшие показатели RPO и RTO по сравнению с традиционными решениями.

Модуль StarWind Backup Appliance поставляется в виде настроенного и готового к работе сервера резервного копирования, построенного на базе StarWind HyperConverged Appliance (HCA). Работа с продуктом происходит через удобный веб-интерфейс StraWind Web UI, есть также плагин StarWind для vCenter.

Высокая производительность и надежность решения достигается как за счет технологии NVMe, так и за счет отделения и изоляции сервисов резервного копирования от производственных данных. При этом сервисы бэкапа StarWind BA нагружают системные ресурсы только тогда, когда начинают выполнять задачу резервного копирования.

Важный момент, который стоит отметить - продукт Backup Appliance от StarWind поддерживается со стороны ProActive Premium Support, а значит, что ваша инфраструктура резервного копирования будет работать 24x7, даже когда вы в отпуске или спите.

Естественно, данные, находящиеся на хранилище резервных копий, надежно защищены с помощью технологий RAID и полностью отделены от сервисов, непосредственно реализующих резервное копирование. Ну а приятный бонус - это то, что вы можете выбрать один из следующих гипервизоров на модуле StarWind BA:

• Microsoft Hyper-V версий 2016, 2019 или 2022
• VMware vSphere версий 6.5, 6.7 или 7.0

На данный момент доступны 2 модели Backup Appliance (BA 30 и BA 60):

Как мы видим, обе модели представляют собой одноюнитовые серверы с 30 или 60 ТБ емкости (это полезная емкость после создания RAID) и 64 ГБ оперативной памяти на борту.

В качестве протоколов доступа к данным поддерживаются следующие:

• iSCSI
• SMB3
• NFSv4.1
• NVMe-oF

Ну и главное - в качестве ПО для резервного копирования используется лидирующий в отрасли продукт Veeam Backup and Replication V10 и V11. Тут можно быть спокойным - он работает надежно и быстро. В качестве системы мониторинга и отчетности можно использовать решение Veeam ONE.

Больше информации о решении StarWind Backup Appliance можно получить на этой странице. Живое демо продукта вы можете запросить вот тут.

Компания StarWind Software, известная многим из вас как ведущий производитель программно-аппаратных хранилищ под виртуализацию VMware vSphere и Microsoft Hyper-V, запустила новый продукт StarWind SAN & NAS, который предназначен для создания хранилищ на основе севреров с установленным там гипервизором. В качестве платформы StarWind SAN & NAS использует Linux...

В начале года компания VMware запустила обновленный портал VMware Customer Connect, пришедший на смену устаревшему и неповоротливому My VMware, использовать который, зачастую, было мучением. Теперь VMware повернулась к пользователям лицом - на портале Customer Connect можно решать основные рутинные задачи, связанные...

На днях компания StarWind, ведущий производитель средств для создания программно-аппаратных хранилищ под виртуализацию, выпустила новую версию своего флагманского продукта - StarWind Virtual SAN v8 for Hyper-V (build 14120). Надо отметить, что в конце марта этого года StarWind уже выпускала обновление Virtual SAN (build 14033), поэтому ниже мы расскажем о новых возможностях обеих версий.

Итак, что нового появилось в StarWind Virtual SAN v8 for Hyper-V в этом году:

1. Компоненты VTL и Cloud Replication

• Поддержка Microsoft Azure - добавлена опция по загрузке файлов в Archive tier напрямую, без необходимости сначала добавлять их в Hot/Cool tier и дальнейшего перемещения в архив.
• Возможность Write Protect для виртуальных кассет.
• Минимальный размер кассеты установлен в 50 МБ.
• Режим VTL file operation mode изменен на принудительное закрытие неиспользуемых файлов. Если в работе слишком много частей виртуальных кассет, то много открытых файлов могло привести к исчерпанию ресурсов. Изменить это поведение теперь можно в параметре closedatafiles в конфиге StarWind.cfg.
• Исправлена ошибка при восстановлении кассет, разделенных на части, из облака (некоторые части могли не загружаться).
• Пофикшена ошибка в cloud replication, которая могла возникать, если установлена опция "Create new empty tapes automatically when existing tape removed from VTL for replication". Если она была включена, это могло привести к падению сервиса при создании новой виртуальной кассеты.

2. Улучшения синхронной репликации

• Исправлена ошибка с отклонением синхронизации HA-узла при перезапуске сервиса на одном из узлов (иногда процедура не стартовала автоматически).
• Исправлена ошибка, приводившая к падению сервиса в случае, если соединение с хранилищем или сетевое соединение испытывало падение производительности.
• Исправлена реализация алгоритма Node Majority failover strategy. Ранее она работала некорректно в случае, если соединение между узлами было нарушено, но только в одну сторону.
• Пофикшена процедура автоматического восстановления для трехсторонней репликации. Ранее она использовала информацию от двух из трех узлов, что некорректно для процедура auto-restore. Теперь учитывается статус от всех трех узлов.
• Поправлено некорректное поведение при операции расширения размера хранилища на узле. Это приводило к разрыву соединения для некоторых случаев, когда операции по работе с хранилищем занимали продолжительное время.
• Исправлена ошибка, которая вела к полной синхронизации вместо быстрой в некоторых случаях.
• Исправлена ошибка с обработкой IO-запросов на одном из хранилищ, приводившая к тому, что в случае зависания запроса на конфигурации с three-way репликацией происходила некорректная работа на всех трех узлах.

3. Основные улучшения

• Улучшения производительности для версии VSA (Virtual Storage Appliance).
• Исправлена проблема с закрытием сессии в случаях, когда обнаруживался критический недостаток ресурсов.
• Исправлена проблема с обработкой операции control connection close - в некоторых случаях это приводило к генерации большого числа нотификаций, а Management Console переставала отвечать.
• Исправлена процедура session close при остановке службы - теперь она не зависает в некоторых редких случаях.
• Исправлена проблема с зависанием Management Console при накатывании бесплатной лицензии на сервер без интернет-соединения.
• Было обновлено лицензионное соглашение.

4. StarWindX PowerShell Module

• Физические устройства теперь есть в общем списке устройств. Их можно использовать для экспорта с физических ленточных устройств.
• Добавлено свойство MaintenanceMode для объекта HA Device.

Загрузить пробную версию StarWind Virtual SAN v8 for Hyper-V можно по этой ссылке. Документация доступна здесь, а Release Notes - вот тут.

Отметим также, что обновился и продукт в формате виртуального модуля для платформы VMware - StarWind VSAN for vSphere (OVF Version 20210520, Version 8 build 14120). Release notes доступны тут (список улучшений там практически такой же, за исключением некоторых моментов в мартовской версии).

Компания StarWind, ведущий производитель программно-аппаратных решений для отказоустойчивых хранилищ под виртуальные машины, представила новое предложение - HCI Evaluation Kit для программно-аппаратных комплексов StarWind HyperConverged Appliance (HCA). С помощью набора для быстрого старта HCI Evaluation Kit вы сможете получить решение на базе вложенных (nested) виртуальных машин, в рамках которого будет работать sandbox-кластер...

Продолжаем рассказывать о лучшем в отрасли решении для создания программных хранилищ под виртуальные машины на базе хост-серверов ESXi - StarWind Virtual SAN for vSphere. Как многие знают, с какого-то момента StarWind стала поставлять свое решение для платформ VMware в виде виртуального модуля (Virtual Appliance) на базе Linux, который реализует основные сервисы хранения, дедупликации и компрессии, а также отказоустойчивости и обеспечения надежности данных в виртуальных машинах.

Для виртуального модуля StarWind работа механизма дедупликации и компрессии обеспечивается средствами Linux-движка Virtual Data Optimizer (VDO), который появился относительно недавно. Это удобный и надежный способ экономии дискового пространства за счет использования дополнительных емкостей оперативной памяти на хосте.

Для начала вам нужно определиться с оборудованием хостов ESXi, где вы будете развертывать виртуальные модули StarWind. Как вы понимаете, в целях обеспечения отказоустойчивости таких узлов должно быть как минимум два.

Что касается HDD и SSD-дисков, то нужно также спланировать конфигурацию RAID на хранилище хостов. Сделать это можно в соответствии с рекомендациями, описанными в базе знаний StarWind. Вы можете использовать программный или аппаратный RAID, о настройках которого мы расскажем ниже.

Что касается дополнительной оперативной памяти на хосте ESXi, то нужно выбирать ее объем, исходя из следующих критериев:

• 370 МБ плюс дополнительные 268 МБ на каждый 1 ТБ физического хранилища
• Дополнительно 250 МБ на 1 ТБ физического хранилища, если включена дедупликация (UDS index)

То есть для 4 ТБ физического хранилища с дедупликацией вам понадобится:

370 MB + 4 * 268 MB +4 * 250 MB = 2 442 MB RAM

Итого 2,4 ГБ оперативной памяти дополнительно к памяти под ОС виртуального модуля. Вообще, StarWind рекомендует 8 ГБ памяти для виртуального модуля - 4 ГБ на машину и 4 ГБ на движок VDO для работы с хранилищем.

Один VDO-том может работать с хранилищем до 256 ТБ, что покрывает максимум потребностей в рамках хранилищ на базе серверов. Также StarWind очень рекомендует использовать дисковые массивы All-flash или NVMe-оборудование.

Общее правило развертывания таких хранилищ таково:

• Под VDO: аппаратный или программный RAID (LVM или mdraid)
• Над VDO: "толстые" (thick) диски StarWind Virtual SAN в режиме stand-alone или HA

Надо понимать, что сам том VDO - это тонкий диск, растущий по мере наполнения, поэтому устройство под ним должно иметь расширяемую природу (MD RAID, LVM).

Примерная схема отказоустойчивого решения StarWind Virtual SAN for vSphere на базе 2 узлов выглядит так:

После того, как вы установите StarWind Virtual SAN, настроите виртуальную машину и StarWind Management Console, нужно будет настроить аппаратный или программный RAID для хранилища.

Если вы используете аппаратный RAID, то просто создайте виртуальный диск для ВМ StarWind Virtual SAN на его хранилище, но обязательно типа "Thick Provisioned Eager Zeroed" (также вы можете использовать RDM-диск):

Если же вы будете использовать программный RAID, то нужно будет использовать HBA или RAID-контроллер в режиме DirectPath I/O passthrough, чтобы получить прямой доступ к дискам и собрать на их базе RAID-массив.

Для этого вам нужно будте выбрать правильный HBA/RAID-контроллер как PCI-устройство:

И пробросить его напрямую в виртуальную машину StarWind:

После этого в StarWind Management Console можно будет собрать RAID нужного вам уровня:

Рекомендации тут такие:

После этого в виртуальном модуле StarWind на полученном хранилище нужно будет создать VDO-устройство с нужными вам параметрами:

vdo create –activate=enabled –deduplication=enabled –compression=disabled –emulate512=enabled –indexMem=%size% –vdoLogicalSize=%size% –device=%yourdevice% -n=%name%

Здесь мы видим, что создается устройство с включенной дедупликацией, выключенной компрессией, нужным размером индексной памяти и заданного объема.

После создания это устройство надо отформатировать в XFS со следующими параметрами:

Далее вы можете создавать хранилище StarWind на этом устройстве и (опционально) сделать его реплику на партнерском узле в режиме HA. Также рекомендуется выставить настройку Disk.DiskMaxIOSize на хосте ESXi

В значение 512:

Ну и про оптимизацию производительности I/O-планировщика прочитайте вот эту статью базы знаний StarWind. Если вам интересен процесс создания хранилищ с дедупликацией и компрессией на базе StarWind Virtual SAN в стиле "от и до", то рекомендуем прочитать вот эту статью.

Недавно у компании VMware появился интересный документ "Performance Characterization of NVMe-oF in vSphere 7.0 U1", в котором рассказывается о производительности протокола NVMe-oF (NVMe over Fibre Channel).

Напомним, что NVMe-oF - это реализация технологии RDMA, которая позволяет не использовать CPU для удаленного доступа к памяти и пропускать к хранилищу основной поток управляющих команд и команд доступа к данным напрямую, минуя процессоры серверов и ядро операционной системы. Еще один его плюс - это то, что он обратно совместим с такими технологиями, как InfiniBand, RoCE и iWARP. Для всего этого нужна поддержка RDMA со стороны HBA-адаптера хоста ESXi.

Поддержка NVMe-oF для доступа к хранилищам появилась еще в VMware vSphere 7, а в обновлении Update 1 была улучшена и оптимизирована. В указанном выше документе рассматривается сравнение производительности традиционного протокола Fibre Channel Protocol (SCSI FCP) с реализацией FC-NVMe в vSphere 7.0 U1.

Для всех бенчмарков использовался тот же HBA-адаптер и инфраструктура сети хранения данных SAN. Для генерации нагрузки использовались утилиты fio (для создания разных по размеру операций ввода-вывода I/O, а также паттернов нагрузки) и Microsoft CDB (бенчмарк для генерации OLTP-нагрузки в SQL Server).

Результат оказался весьма интересным. С точки зрения IOPS протокол NVMe-oF смог выжать почти в два раза больше операций ввода-вывода практически для IO любого размера:

Задержка (Latency) также снизилась практически в два раза:

На картинке ниже приведены результаты теста Microsoft CDB для базы данных в числе транзакций в секунду:

Здесь также виден значительный прирост для NVMe-oF, а для двух виртуальных машин производительность выше почти в раза!

Остальные интересные детали тестирования - в документе.

Многие из вас знают про лучшее на рынке программно-аппаратное решение для организации хранилищ под виртуализацию StarWind Virtual SAN. О прошлом его обновлении, которое вышло весной этого года, мы писали вот тут.

Недавно компания StarWind выпустила обновление этого продукта в виде виртуального модуля OVF на базе Linux для VMware vSphere - VSAN OVF Version 20201027 Version 8 (build 13861).

Давайте посмотрим, что там появилось нового:

Общие улучшения и багофиксы

• Обновлено ядро модуля Linux Kernel.
• Настройка iScsiPingCmdSendCmdTimeoutInSec теперь по умолчанию выставлена в 5 секунд.
• Исправленный процесс логирования для оповещений по email, теперь они не смешиваются с общими событиями почтового сервера.
• Улучшены операции по остановке службы (ранее этот процесс мог подвиснуть в определенных обстоятельствах).
• Обновлена имплементация SCSI-протокола для более корректного процессинга команд UNMAP/TRIM.

Улучшения синхронной репликации

• Добавлена опция использования SMB-шары как ресурса witness для устройств с синхронной репликацией.
• Исправлена обработка персистентных резерваций для устройств с синхронной репликацией.
• Исправлены некоторые случаи обновления состояния партнерского узла после восстановления из ситуации split-brain.

Управляющая консоль (Management Console)

• Исправлено падение консоли, когда StarWind Event log содержал записи с некорректными строковыми значениями.
• Обновлен диалог настроек нотификаций по email (добавлена валидация и спрятаны поля логина-пароля при отсутствии необходимости аутентификации).

Модуль StarWindX PowerShell

• Добавлена возможность добавления HA-устройств в конфигурации Node Majority. Теперь узел StarWind или SMB-шара могут быть использованы как witness. Более подробно об этом можно узнать из примеров сценариев CreateHAPartnerWitness.ps1 и CreateHASmbWitness.ps1.

• Поправлена обработка параметра ALUA для командлетов по созданию HA-устройства.

Скачать пробную версию StarWind Virtual SAN для VMware vSphere в формате виртуального модуля OVF можно по этой прямой ссылке.

Некоторое время назад мы писали о технологии Remote Direct Memory Access (RDMA) которая позволяет не использовать CPU сервера для удаленного доступа приложения к памяти другого хоста. RDMA позволяет приложению обратиться (в режиме чтение-запись) к данным памяти другого приложения на таргете, минуя CPU и операционную систему за счет использования аппаратных возможностей, которые предоставляют сетевые карты с поддержкой этой технологии - называются они Host Channel Adaptor (HCA).

Устройства HCA могут коммуницировать с памятью приложений на сервере напрямую. Грубо говоря, если в обычном режиме (TCP) коммуникация по сети происходит так:

То при наличии на обоих хостах HCA, обмен данными будет происходить вот так:

Очевидно, что такая схема не только снижает нагрузку на CPU систем, но и существенно уменьшает задержки (latency) ввиду обхода некоторых компонентов, для прохождения которых данными требуется время.

Поддержка RDMA появилась еще в VMware vSphere 6.5, когда для сетевых адаптеров PCIe с поддержкой этой технологии появилась возможность обмениваться данными памяти для виртуальных машин напрямую через RDMA API. Эта возможность получила название Paravirtual RDMA (PVRDMA).

Работает она только в окружениях, где есть хосты ESXi с сетевыми картами с соответствующей поддержкой, а также где виртуальные машины подключены к распределенному коммутатору vSphere Distributed Switch (VDS). Метод коммуникации между виртуальными машинами в таком случае выбирается по следующему сценарию:

• Если две машины общаются между собой на одном ESXi, то используется техника memory copy для PVRDMA, что не требует наличия HCA-карточки на хосте, но сама коммуникация между ВМ идет напрямую.
• Если машины находятся на хостах с HCA-адаптерами, которые подключены как аплинки к VDS, то коммуникация идет через PVRDMA-канал, минуя обработку на CPU хостов, что существенно повышает быстродействие.
• Если в коммуникации есть хоть одна ВМ на хосте, где поддержки RDMA на уровне HCA нет, то коммуникация идет через стандартный TCP-туннель.

Начиная с VMware vSphere 7 Update 1, для PVRDMA была добавлена поддержка оконечных устройств с поддержкой RDMA (Native Endpoints), в частности хранилищ. Это позволяет передать хранилищу основной поток управляющих команд и команд доступа к данным от виртуальных машин напрямую, минуя процессоры серверов и ядро операционной системы. К сожалению для таких коммуникаций пока не поддерживается vMotion, но работа в этом направлении идет.

Чтобы у вас работала технология PVRDMA для Native Endpoints:

• ESXi должен поддерживать пространство имен PVRDMA. Это значит, что аппаратная платформа должна гарантировать, что физический сетевой ресурс для виртуальной машины может быть выделен с тем же публичным идентификатором, что и был для нее на другом хосте (например, она поменяла размещение за счет vMotion или холодной миграции). Для этого обработка идентификаторов происходит на сетевых карточках, чтобы не было конфликтов в сети.
• Гостевая ОС должна поддерживать RDMA namespaces на уровне ядра (Linux kernel 5.5 и более поздние).
• Виртуальная машина должна иметь версию VM Hardware 18 или более позднюю.

За счет PVRDMA для Native Endpoints виртуальные машины могут быстрее налаживать коммуникацию с хранилищами и снижать задержки в сети, что положительно сказывается на производительности как отдельных приложений и виртуальных машин, так и на работе виртуального датацентра в целом.

Многим из вас знакомы продукты компании StarWind, предназначенные для создания отказоустойчивых хранилищ под различные платформы виртуализации. Одним из лидеров отрасли является решение StarWind Virtual SAN, у которого есть множество функций хранения, обеспечения доступности и защиты данных. А сегодня мы поговорим еще об одном бизнесе компании StarWind - программно аппаратных комплексах для специальных задач...

Производительность дисковой подсистемы в Linux зависит от различных параметров и настроек, одной из которых является тип планировщика для работы с потоком ввода-вывода (I/O scheduler). Если вы планируете использовать продукт StarWind VSAN for vSphere для создания программных хранилищ на базе виртуальных машин Linux (Virtual Storage Appliance), то информация ниже может быть вам полезна.

В зависимости от типа целевого хранилища, иногда целесообразно поменять используемый тип планировщика. Чтобы вывести текущий тип I/O scheduler, нужно выполнить следующую команду для выбранного устройства:

# cat /sys/block/sda/queue/scheduler
noop [deadline] cfq

В данном случае мы видим, что тип планировщика - это noop (он же none). В зависимости от версии ядра Linux, он также может быть выставлен как mq-deadline. Кстати, обратите внимание, что тип планировщика указывается на уровне отдельного дискового устройства.

Считается, что для SSD и NVMe-устройств лучше ставить планировщик none / noop, который уменьшает нагрузку на CPU, а вот для HDD-дисков лучше использовать mq-deadline, который показывает лучшие результаты по итогам синтетических тестов.

Чтобы поменять планировщик на noop для диска sdb, нужно выполнить следующую команду:

# echo noop > /sys/block/sdb/queue/scheduler

Потом надо обязательно проверить, что планировщик поменялся, следующей командой:

# cat /sys/block/sdb/queue/scheduler
[noop] deadline cfq

Но это все меняет тип планировщика на время, до перезагрузки, чтобы вы могли проверить разные планировщики и сделать тесты производительности. Чтобы сохранить эти изменения, нужно изменить файл scheduler.rules в директории /etc/udev/rules.d/

Например, если вы хотите поменять планировщик на noop для устройства sdb и установить политику "no read ahead" для него, то нужно добавить туда следующую строчку:

ACTION=="add|change", SUBSYSTEM=="block", KERNEL=="sdb", ATTR{queue/scheduler}="noop", ATTR{queue/read_ahead_kb}="0"

Рекомендуется выставлять одинаковый тип планировщика на всех узлах, где расположены хранилища StarWind VSAN. Также надо отметить, что последние версии продукта StarWind VSAN for vSphere при установке автоматически выставляют тип планировщика noop для SSD-хранилищ.

Как многие из вас знают, у компании StarWind, выпускающей лучший продукт Virtual SAN для создания программных iSCSI хранилищ под виртуализацию, есть и программно-аппаратный комплекс HyperConverged Appliance (HCA). Чтобы управлять этим решением в контексте всей инфраструктуры, существует продукт StarWind Command Center, на который мы сегодня посмотрим.